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INTRODUCTION 



During the early 1960's when the dual state third gen- 
eration computers were deve 1 opecj/ t he concept of virtualiza- 
tion was born* Little did one recognize the potential bene- 
fits or rapid transition that would soon take place in the 
coinouter field in the area of virtual machines,, 

Even though this raoid change and increased complexity 
may lead to the frustrations expressed by John Gosden/ Vice 
President/ Eauitable Life Assurance Society [18] * 



11 All of these new announcements are a nui ssance* 
irte'd rather be getting on with doing productive 
work than tryinq to keen aligned with the 
industry's technology* 11 



However/ the virtual machine concept has arrived and is hero 
to stay. Robert P. Goldberg [111 notes that 



'* Virtual machines have finally arrived* Dismissed 
for a number of years as merely academic curiosi- 
ties/ thev are now seen as cost-effective tech- 
niques for oraani ?inq computer systems resources 
to provide extraordinary system flexibility and 
support for certain uni aue applications*" 



and Phil Rook man/ President/ Innovation Data Processing [18] 
satirically comments 

"Virtual computing is complicated/ but if it's 
simplicity you want / oet a bank of 1401* s. M 

The current state-of-the-art of virtual computing is still 
in its infancy and its potential is ripe for tapping/ espe- 
cially in an educational institution. 
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the Naval Postgradu 



In the fall of 1974 and early 1975? 
ate School acaui red two Digital Equipment Corporation 
PDP-11/50 computers as a part of the Signal Processing and 
Disolay Research Facility. It will also serve as a valuable 
tool for the computer science student. 

With the enchancement of virtualization? this comouter 
system would increase in both flexibility and potential 
uses. Virtual machine systems can be used to resolve a 
number of problems that face a student of computer science. 
All students could be given their own virtual computer for 
exploring new ideas and concepts. The student could imple- 
ment and test software from the basic hardware level to the 
operating system level without the fear of destroying or 
interfering with the real system. Courses can be made avail- 
able where the fundamentals of advanced software and the 
design and analysis of operating systems are accomplished in 
6 'hands-on' environment. 

Besides an educational need for virtual machine's there 
exists the problem of security and privacy. Computer tech- 
nology has spawned a whole new field of crime and generated 
a series of problems for both designers and users of infor- 
mation systems. There are truly very few systems that can 
be classified as secure. Particularly in the military en- 
vironment? security is a ever present problem and a major 
concern of students who will leave this educational insti- 
tute and work in a military computer installation. The vir- 
tualized co m outer holds great promise as the solution to 
this ever growing problem. It would for example? be possible 
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for the PDD-11/50 to interorate classified and unclassified 



processes without degrading the performance of the system 
and without the fear of possible compromise. It would also 
eliminate the the current locked door ’monoprocess inq' en* 
vironment policy for processing classified jobs. 

Another need that can tie solved bv using a virtual com- 
puter is in system development. New enhancements to the 
operating system could be throughly tested and debugged in 
’day light hours' and in a multiprogramming environment 
before being place 'on-line'. The concept of virtualization 
is truly an exciting area of computer science and one in 
which the effects on the data processing community are just 
beginning. 

The remainder of this thesis is divided into five addi- 
tional chapters. 

In chapter I I r the background and principles of virtual- 
ization a^e explored to develop a basic understanding of the 
virtual machine and the current terminology associated with 
it. A glossary (Appendix A) is provided for the convenience 
of the reader. 

Chapter III gives a summary of the architectual design 
of the PDP-11/50 family of computers and highlights some of 
the unsuitabilities of this type of architectural desian 
for virtualization. 

Chanter IV presents the problems of virtualizing the 
PDP-ll/50 and examines some possible solutions to these 
problems to include recommenced milestones towards the ulti- 
mate goal of a f u 1 1 v virtualized Pi) P-1 1/50. 



The selection of on approach to virtualize the P D p - 1 1 / B 0 



and implementation of this apDroach is o resented in Chapter 
V. A user manual (Appendix D) is also provided. 

Both chapters IV and V are self-contained and those who 
are knowledgeable about current virtual machine anpl ications 
and technology should be able to s«ip directly to these sec- 
tions. 

Chapter VI summarizes the conclusions of this implemen- 
tation and contains some suggestions for further develop- 



ment 



II. V I 3 T t ! AL MACHINES - PRINCIPLES A N D TERMINOLOGY 



A. PRINCIPLES AND TERMINOLOGY 

The virtual machine can basically be pictured as an ima- 
ginary c c o y of some real existing computer system but with 
the capability of executing real programs . This unique and 
rather new idea has introduced to the computer world the 
concept of mu 1 t i -en v i r on men t i nq as compared to multi- 
programming and multi -processing. In extending the basic 
idea of the virtual machine* one is lead to the realization 
that one real computer can create many imaginary computers* 
each of which may have different hardware characteristics 
and devices. In addition* each imaginary machine may support 
different operating systems. 

"Basically a virtual machine is a very efficient simu- 
lated copy (or copies) of the bare host machine f 1 3 ) ft • A 
bare host machine is simply a machine w i t h o u t its accom- 
panied software* i.e. operating system. If we included the 
operating system's instruction set (system calls* I / 0 1 s * 
etc.) along with the basic hardware instructions 
( MOV * BR * e t c . ) * we have introduced the instruction set for 
the extended machine i . e . * the bare machine plus operating 
system is the extended machine. 

The virtual machine may be further defined as an effi- 
cient* isolated* duplicate of a real machine. It first must 
be efficient* meaning that the programs executing under the 
virtual machine should basically r u n at speeds comparable to 
execution on the real machine. This attribute of a virtual 



machine makes it reasonable to run production type jobs on 
the virtual machine* 

1 h e efficiency aspect of the virtual machine is realized 
by having the majority of instructions of a program running 
on the virtual machine executed directly on the real host 
com outer. This concept rules out traditional emulators and 
complete software interpreters/ for' both methods Demand 
total interpretation of all urogram i ns t rue t i ons . 

Secondly* the reason the virtual machine must be isolat- 
ed from the rest of the system is to insure that it has com- 
plete control over managing its own systems resources^ and 
that no unintentional interference exists between the real 
and virtual system. 

Finally/ the virtual machine must produce a duplicate or 
essentially identical environment of real machines to make 
it practical to run real jobs on them. M Since a virtual 
machine is a software-hardware duplicate of a real existing 
computer system there is always the notion of a real comput- 
er system or real machine/ whose execution is functionally 
eaui valent to the v i r t u a 1 machine ( 1 3 ] . " If one must modify 
a job to be executed on a virtual machine because the virtu- 
al machine is slightly different from the real machine* then 
the virtual machine concent has loss its beauty/ value* and 
practicality fl31. 

It should be obvious that certain tvpes of instructions 
can not be allowed to bn executed directly but must be simu- 
lated by the virtual machine. The job of identifying and 

i s 



trapping that type of instruction 



the heart of the 



virtual machine. The program that executes on the real host 
machine creotino the virtual machine environment is called 
the virtual machine monitor. Its function is to be the 
software interface between the real system and virtual sys- 
tem. 

Figures 1 and ?. [3] illustrate the basic differences 
between the conventional computer system and a virtual 
machine organization. The conventional dual state extended 
machine architecture contains only one basic machine inter- 
face which can support many user programs but is only capa- 
ble of running one privileged software nucleus at a given 
time. As contrasted in figure ?. / the virtual machine op- 
proachf the virtual machine monitor creates additional basic 
machine interfaces which are functionally identical to that 
of the real machine. Thus any orivilegeo software nucleus 
that will run on the real machine will execute on the virtu- 
al machine. It is interesting to note, that the privileged 
software nucleus has no way of knowing whether it is beino 
executed on the real or virtual mac nine. 

Figure 2 should not imply that the basic machine inter- 
face supported by the virtual machine monitor must be ident" 
ical to the interface of the bare machine that the virtual 
machine monitor runs on, i.e. a virtual IBM S/360 50 need 
not be produced on a real S/360 50 c However/ when the inter- 
face is not identical they will be/ at the minimum/ of the 
same computer family. /Jhen two interfaces are completely 
different (IBM S/360 versus BURROUGHS 6700) then emulation 
or simulation must be employed to mop the one system 



CONVENTIONAL EXTENDED MACHINE 
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15 



VIRTUAL MACHINE ORGANIZATION 



LU 

Z 




16 



architecture into another different architecture. 

The question that might he logically asked at this ooint 
is: "Are there any restrictions on the type of orograrns that 
can be processed on a virtural machine?”. Surprisingly* 
there is basically only one type of program that, will not 
execute properly on the virtual machine and that is a pro" 
gram with timina dependencies. This type of program while 
once popular is now extremely rare. Reference 24] provides a 
detailed insight into this area. 

The virtual machine can now be formally defined as fol- 
lows [241 : 

11 A virtual computer is a hardware-software dupli- 
cate of a real existinq computer system in which a 
statistically dominant subset of the virtual 
processor's instructions execute directly on the 
host processor in native mode. " 



The method of producing a virtual machine to meet the 
above stated definition may vary greatly. The method would 
depend on such things as the specific brand and model of 
com outer#- the degree of efficiency required* and tne i n~ 
genuity of the programmer of the virtual machine monitor. 
There is no one best approach or method. The virtual 
machines that have been produced to date though* can be 
categorized into general types depending on the method of 
implementation [3*13*14] . 

A t y o e I monitor is illustrated by f i g u r e 2 . Here the 
virtual machine monitor runs directly on the bare machine* 



where as the t y r> e II monitor (figure 3 ) runs on the extended 
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machine under an operating system. 

A type I monitor's only function is to produce one or 
more virtual bare machines which will support any operating 
system that the real bare machine would support. 

The type II monitor* on the other h a n d ^ car'! take advan- 
tage of the services provided by its operating system* For 
instance* such features as the memory management* the actual 
paginq mechanism* and I/O ooerations of the operating system 
can be used. 

When the virtual machine is identical to the host pro- 
cessor then we say that the virtual computer system is 
self-virtualizing. When it is not identical* then the virtu- 
al machine must* as earlier stated* be of the same processor 
family as the host machine and is said to be family virtual- 
izing. An example of family virtualizing is an IBM system 
370/155 as the host machine which is supporting a virtual 
system 360/50 machine. 

One very apparent benefit of family virtualizing is in 
upgrading the computer in a data processing installation* 
Here the old system could be virtualized to process all jobs 
that have not been reorogromrned to meet the new systems 
requirements. Reproqrammina then would not be a critical 
factor but could be accomplished in a timely* directed 
manner. In fact* some application programs which are pro- 
cessed very infrequently mav never be selected for re pro- 
gram mi no. 

Recursive virtualizin'* is when an additional copy or 
copies of the virtual machine monitor run on the virtual 

\ 
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system or systems that have been produced by the host com- 
puter. We have then in effect/ produced another level of 
virtual machines. Figure 4 illustrates this recursive pro- 
perty/ and the concepts of levels of virtual machines. 

It is interesting to note that recursive virtualizing is 
supported only under the se 1 f - v i r t ua 1 i z i ng type system. The 
main reason for this restriction is the fact that the virtu- 
al machine monitor is tailored to interface with a specific 
model of computer/ and therefore/ it is only possible to run 
the monitor when the identical interface is produced. 

One can see that this property is indeed recursive/ for 
level 2 in fioure 4 is another virtual machine monitor and 
could have in effect recursed again and produced a third 
level virtual machine and so forth. Tests have successfully 
been conducted over a six level recursion [121. 

One main advantage of practical importance in recursive 
virtualizing is the ability to test and modify the virtual 
machine monitor itself without interfering with normal pro” 
cessing. 

B. BASIC REQUIREMENTS FOR VIRTUAL MACHINE SYSTEMS 

Since the majority of instructions of application pro- 
grams running on a virtual machine are going to execute 
directly on the host comouter without any software interven- 
tion/ a method must be derived to trap only those "critical 
instructions" that must not be allowed to be executed. Be- 
fore addressing this traopinq process/ more fundamental 
questions should first be considered/ namely "What is a 
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critical instruction?” and "How can one identify them?”. 

Basically the third generation of com outers created two 
distinct processor modes of operation (privileged - •super- 
visor* and nonpri vi I eaed - •program 1 )* The supervisor mode 
permitted certain •privileged* instructions to be executed 
which are denied execution in t n e user mode* Privileged 
instructions then ere those instructions which ere allowed 
to be executed in the supervisor but not in the program 
mode. These privileged instructions typically control crit“ 
ical system features such as testing and initiating 
i nput/outout facilities or modification of address mapping 
mechanisms* rthen the user requires the execution of a 
privileged instruction the user program executes a supervi- 
sor call to the operating system. This privileged instruct 
t i on is then executed on behalf of the user program. 

Professor Robert P. Goldberg in his Ph.D thesis (131 on 
virtual machine architecture defined the critical instruct 
tions as the following: 

M A sensitive instruction is an instruction 
which* because of 3rd generation virtual machine 
software construction will give incorrect results 
if permitted to be executed directlv on the host 
computer" . 

It is now obvious that sensitive instructions encoun- 
tered in the virtual system cannot be allowed to execute 
directly* since the execution of sensitive instructions 
could prevent the correct interpretation of certain instruc- 
tions. 



He states the key to implementing a virtual machine on a 



third generation system is to provide comolete functional 
equivalence with a real machine without allowing the direct 
execution of sensitive instructions. 

Sensitive instructions are divided into two general 
types* namely* control sensitive and behavior sensitive 
instructions, 

1, Control sensitive instructions are those 
instructions which control the resources and en- 
vironment of the system. Examples of such instruc- 
tions are those which attempt to change available 
memory* start an I/O operation# or change the pro- 
cessor mode, 

2 . Behavior sensitive instructions are those 
instructions whose execution depends upon their 
location in real memory. An example of such an 
instruction is the system / 3 fe 0 LRA (load physical 
address) instruction. 

The machine instruction renertoi re of the host computer 
system must be individually analyzed to determine their sen- 
sitivity. Each instruction should be questioned as to wheth- 
er its execution could produce a possible erroneous results 
if allowed to execute in the unprivileged mode. This iden- 
tification and analysis appears to be like a fairly si mole 
process* but in reolity before this can be accomol i shed* a 
thorough understanding of both the machine language and 
hardware characteristics must be mastered. 
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Onc^ the sensitive instructions have been identifed; it 
is now Possible to determine if the computer system will 

supoort a virtual machine* Professor Goldberg’s First 
Theorem on virtual inability gives us this answer [24]. 

" THEOREM 1 : For any conventional third generation 
computer; a virtual machine monitor may be con- 
structed if the set of sensitive instructions for 
that computer is a subset of the set of privileged 
instructions.” 

The basic philosophy behind Theorem 1 is the following. 
If all sensitive instructions are a subset of the privileged 
instructions; then the host computer has a very convenient 
built-in trapping method. Any attempt to execute a 
privileged instruction in the program mode will generate a 
machine interrupt. Therefore; if the virtual machine’s 
privileged software is running in the program state then an 
interrupt will be generated when the virtual machine’s 
operating system attempts to execute any privileged instruc* 
tions. Since the sensitive instruction is a subset of the 
privileged instructions set; it is just a matter of checking 
to see if the privileged instruction causing the interrupt 
is sensitive. 

This class of interrupts can then be turned over to the 
virtual machine monitor for servicing. If it is a sensitive 
instruction that generated the interrupt then it will be 
simulated. If not; it will be returned to the host operating 
system for execution. Figure 5 illustrates this interaction. 
The interested reader should refer to reference [24] * o r 



proof of Theorem i 



TRAP SENSITIVE INSTRUCTION 
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This rather simple theorem suprisinqly proves that very 
few third generation architectures are virtual izable? for it 
only takes one instruction to cause the monitor to be 
forced to interrogate all instructions to prevent the execu- 
tion of the one exception. This of course would cause the 
virtual machine to lose its efficiency and value. It should 
be realized? however? that third generation computers were 
not designed to support virtual machines? and it is their 
dual state nature that brought about the virtual machine 
concept in the first place. 

C . HYBRID VIRTUAL MACHINE SYSTEMS 

Since the majority of third generation computers are not 
virtual izable the hybrid- virtual machine monitor was intro- 
duced. Here sensitive instructions are further classified 
into two groups depending on where they can be located? i.e. 
are thev only located in the supervisor area of coding 
(supervisor sensitive) or can they be in the user area (user 
sensitive)? 

Once the user and supervisor sensitive instructions are 
identified then Goldberg's Third Theorem can oe applied? 
which is the following 1 2 4) S 

"THEOREM 3. A hybrid virtual machine monitor may 
bP constructed for any conventional third genera- 
tion machine in which the set of user sensitive 
instructions are a subset of the set of privileged 
instructions." 

The main difference then between the virtual machine and 
the hybrid virtual machine is: in the degree of instruction 
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i n t co re t a t i on • 



In the hybrid virtual machine all instruc- 



tionsf privileged or not, in the virtual supervisor mode are 
interpreted. User sensitive instructions will be trapped as 
previously mentioned. 

Figure 6 is an overview that compares instruction in- 
terpretation versus direct instruction execution for normal 
processing, virtual machine processing, hybrid processing, 
and for complete simulation. It should be remembered that 
the more time spend in interpretation the slower the execu- 
tion of the job. 

D. THE VIRTUAL MACHINE MONITOR 

The virtual machine monitor controls the overall virtual 
machine system. The monitors main functions are to create 
the virtual' machine or machines, to monitor and allocate 
their resources, to interrogate all trapped instructions for 
sensitivity, and to simulate the execution of the sensitive 
instructions. 

The virtual machine monitor’s software is composed gen- 
erally of three groups of program modules plus numerous con- 
trol tables (figure 7). The three groups are the dispatcher, 
allocator, a n d the interpreters. The control tables depict 
all the virtual machines resources available and their 
current status. These tables are similiar to the normal 
operating system’s tables and control blocks. 

The dispatcher is the too level control module of the 
virtual machine monitor. It is the initial program that 
receives the machine interrupts and determines if the 
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instruction that is trapped is sensitive. If it is sensitive 
then the dispatcher decides which modules to call to ser- 
vice this action. If it is a resource request or a resource 
modification, then the dispatcher will invoke the allocation 
module. If the action calls for a sensitive instruction to 
be simulateo then one of the interpreter modules will be 
cal led. 

The allocation module is the main keeper of the control 
tables for the virtual machines. It is through this module 
that all the virtual machine devices are created and con- 
trolled. When the virtual machine monitor is supporting mul- 
tiple virtual machines, the complexity of this module is 
significantly increased. It now must keeo track seDaratel v 
of the individual resources of each virtual machine. 

The last group of program .modules that make up the vir- 
tual machine monitor is composed of many individual modules 
called interpreters. There is generally one interpreter 
routine for each identified sensitive instruction. Each 
interpreter routine will simulate an instruction execution 
by changing the state of the virtual machine so as to re- 
flect its actual execution. 

All software - be it an operatina system, application 
program running undpr the operating system, or a stand-alone 
program executing on the virtual machine - must execute in 
the nonorivileged program mode of the host computer. This is 
essential so that the real machine's interrupt can trap sen- 
sitive instructions. It should be obvious that a type I 
virtual machine monitor must execute in the supervisor 
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stater since it is in fact/ the total operating system for 
the real hardware. The type II virtual machine on the other 
hand/ has a choice between supervisor and prooram state. 

If a tyoe II monitor is allowed to operate in the super- 
visor stater then the relationship and coordination between 
it and the operating system must be carefully thought out 
and designed to insure that there is no unintentional in- 
terference. If the monitor is executed in the privileged 
mode? then it could execute within itself the privileged 
instructions that may be required to be actually executed 
after either being trapped or required by some interpreter 
module. It would thereby save the time of requesting and 
waiting for the operating system to execute them. 

If on the other hand» the monitor is running in the pro- 
gram state then the interface problem with the operating 
system is nonexistent. All privileged instructions that are 
required to be executed must be turned over to the operating 
system. This would probably require some additional supervi- 
sor calls to be added to the system/ but it would also make 
the virtual machine monitor smaller and less complex. 

E. SOFTWARE A, NO HARDWARE REQUIREMENTS 

The hardware and software requirements of the host com- 
puter system must meet the following criteria to adequately 
support a virtual computer system. 

1. The method of instruction execution of 
non “privileged instructions in both supervisor and 
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program s t o t o must be roughly equivalent* This is 
important because the ooeratinq system of the v i r «* 
tual machine# which normally operates in the su- 
pervisor state# will be executing in the program 
state* There is also the reverse problem of the 
privileged instruction in the program state not 
causing machine interrupts. For example/ in the 
PDP tl family of computers certain instructions 
are ignored if they are encountered while in the 
progr am state. 

2 . A method of automatically signalling the 
supervisor when the virtual machine attempts to 
execute a sensitive instruction must be available* 

3. A method of orotecting the supervisor and 
any other virtual machine must be available to 
insure isolation of all systems. 

4. The host computer should support a page 
or segmentation type virtual memory system to ade- 
quately give the virtual machines their own virtu- 
al memory required to hold its virtual operating 
system olus its own application programs. 

F. ADVANTAGES AND APPLICATIONS OF VIRTUAL MACHINES 

The advantages of a virtual machine have intentionally 
been left until now/ because many of the b e n e f i t s car') be 
better appreciated once one has a good understanding of th** 
concepts and workings of virtual machines* In facte because 
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virtual machines lend themselves to so many practical a d p 1 i - 
cations* it is felt by many computer experts that the "next 
generation" of computers will be specifically design^ to sup- 
port virtual machines* 

The following outlines a few of the more i ^oortant ad* 

) 

vantages and applications of the virtual machine [19]* 

1 • Software Development For The System Programs, 

Because system programs cannot run under the normal 
operating system in a production tyoe environment* most sys- 
tem programming work must be accomplished in a stand-alone 
environment* and generally in the middle of the night* It 
also causes the system to be brought down which interfers 
with normal processing and is wasteful of system resources* 
not to mention the inconvenience for both system and appli- 
cation programmers* Using a virtual machine for system 
software development eliminates that type of a working en- 
vironment* System enhancement* new operating system 
releases* or in fact any software development can be 
thoroughly tested and debugged on the virtual machine before 
being released* All of this can be accomplished during nor- 
mal working hours and without wasting system resources*. 

2 . Elimination Of Certain Conversion P r o b 1 e m s * 

This benefit was earlier examined and can only be 
truly appreciated when one has lived thro u ah a mass conver- 
sion effort. The ability to be selective on what programs to 
convert and not to be rushed in that conversion is alone a 
great advantage * 

3 « Concurrent Punning Of Dissimilar Operating 
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’A , 

1 ' I ' - 

Systems 13 y Different ! J s n r s , 

This application would be extra m 1 y useful to those 
data processing installations that are charged with the 
responsibility of developina application software which will 
be distributed to many installations and run on a variety of 
computer sizes and models and under different operating 
systems. In fact* copies of the actual operating system of 
the individual installation in which the program will be 
running could be sent to the testing installation. Then the 
program could be executed on a virtual machine configured to 
the installation and tested under their operating system. 

Another benefit of running dissimilar operating systems 
is computer backup capability. If an installation’s compute 
er went "down for an extended period of timer the installa- 
tion could still process necessary jobs on a virtualized 
system using their backuo installation’s computer. They 
could use their own oceral i ng system and configuration 
thereby avoiding the difficult tasks of temporarily modify- 
ing or Generating operating systems or programs generally 
required when one has to move their processes to another 
computer, 

4 , Testing Future Haro ware. 

The virtual machine gives the installation the abil- 
ity to aesian/ develop* and test programs that will bn in- 
terfacing with new hardware before the actual hardware is 
delivered. In addition to helping in the program develop- 
ment* it could have been used in the hardware selection pro- 
. Different types and models of hardware devices could 

3a 



cess 



hove been virtualized and tested for their applicability. 

5 • Test Of Network Facilities, 

The complicated nature of test i nq and implementing a 
computer network would be greatly simplified if many of the 
inter-communication software Pugs can be found and corrected 
on the system before the actual implementation. 

6* Evaluation Of Program behavio r. 

The nature of the virtual machine monitor lends 
itself to a type of Performance monitoring. Detailed in- 
teractions between the software and machine or between 
software modules themselves can be tramped.* measured* and 
recorded to be later printed cut for detailed analysis. 
Changes could be implemented and measured again to check the 
improvement factor before making the real modifications. 

7 • S ecurity And Privacy • 

The virtual computer system holds great premise in 
the area of security and Privacy. As mentioned earlier* it 
is impossible for an operating system to tell if it is being 
executed on the real or virtual machine. Each machine vir- 
tual is completely isolated from each other so it would oe 
impossible to spy on or try to alter any coexisting machine. 

8 • E d u c a t i o n . 

The ability for a student in the computer science 
field to be able to have his own computer and operating sys- 
tem is a blessing to both student and computer center 

manager. Here he can work with and alter on his own an 

operating system, without the underlying fear of destroying 

the real system* for the only way to truly learn about 



ooe r a t 



irig systems is to actually perform 



system maintenance 



on a real 



system. 



III. ARCHITECTURAL DESIGN OF THE PDP-11/50 



This chanter is primarily designed to highlight only 
certain areas of the architectual design of the PDP-11 fami- 
1 y of computers. Attention is mainly given to ccmouter 
design characteristics which relates to virtualization prob- 
lems. It is not intended as a complete or detailed analysis 
of the internal com outer workings. The interested reader 
will find a complete and detailed description in references 
[7] and [81 . 

The PDP-11/50 is a general purpose, interrupt driven, 
three state computer, capable of directly addressing 2 6 '< 
sixteen bit words of memory without the memory management 
unit, and 124k words with memory management. It contains two 
independent sets of six general purpose reai sters, t hree 
stack pointer registers (one SP for each state), and a pro- 
gram counter register (PC). 

The PDPrll/50 in addition to the optional memory manage- 
ment unit, supports an ont. ional floating point processor, 
and a host of peripheral devices. The system is designed to 
support a virtual memory rr.ul t i progrorr.rni ng environment. The 
basic relationship of these different units are depicted in 
figure 8 . 

The general puroose registers are rather unique in that 
I/O operations do not disturp their contents and secondly, 
they can be used in a diversity of register operations, 
namelv as accumulators, index registers, stack pointers, 
autoincreme r<t and autodecrement registers. 
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The instruction set is probably the most powerful asset 
of the PDP-11/50 commuter. The instruction set consists of 
over four hundred m i c roproqrammed instructions* Instruc- 
tions are so flexible that a programmer has numerous options 
available for codinq any Program routine. 

The architectural design feature of the PPD-ll family 
of computers that distinguishes it from other DEC systems as 
well as from other computer vendors is the UNIBLJS. The 
UNIBUS is a high speed (five million bytes/seconds) / 
asychronous* bidirectional channel that ties all system com- 
ponents together (figure 9). 

All memory and processors are connected to the UNIBUS in 
a regular manner. The same addressing scheme is applied 
egually well to a specific device* memory or processor. This 
greatly simplifies I/O programming because the entire in- 
struction set is available for inout/output routines. 

Machine instructions that effect the UN I BUS operation 
or devices attached to the UNIBIJS would gualify as sensitive 
instructions. 

The PDP-11/50 is a three state machine* as compared with 
the conventional two state (supervisor and program) opera" 
tion. Ihe three states or modes are kernel* supervisor* and 
user. Kernel mode programs are unrestricted in their use of 
the machine while the programs operating in the user and 
supervisor modes are restricted in the kind and number of 
instructions which may be legally executed. The supervisor 
(Ttooe is only slightly more Powerful than the user mode. 

It is interesting to note some instructions (RESET*SPL* 
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ANY ATTACMENT CAN BE UNIBUS MASTER 



etc.) are ionorea if not in the kernel mode while other 



instructions (HALT) qenerate an interrupt. This i n consis- 
tency? especially when encountered in the sensitive instruc- 
tion set? adds to the complexity of virtualizing the PDP-11 
family of computers. 

The processor status word (PS) is a special memory cell 
located in the upper 4k of the machine's memory. (The upoer 
4k is not actual memory but addresses of device registers 
located on the device.) The current machine operation mooe 
at any given instance is completely determined bv the 
current mode bits in the PS. 

The PS may be changed in one of three ways: (1) Explici- 
ty? by physically modifing it via a normal machine instruc- 
tion such "as MOV. (P) Implicitly? throuah the use of one of 
the several machine instructions such as SPL?RTT?RTI which 
cause the PS to be implicit/ changed? and (3) Asynchronous- 
ly? as a result of an interrupt or trap. 

The ability to explicitly modify the PS and in fact to 
do any actual I/O is a function of whether or not the 
program's virtual address soace is mapped into that portion 
of the machine's Physical memory which contains the PS ana 
device registers. Programs operating in the user or super- 
visor mode are generally restricted in this manner causing 
for example? I/O to be initiated only from the kernel it- 
self. Figure !0 illustrates the real and virtual memory map. 

Instructions capable of modifying the PS ( SPL ? R T I ? R T T ) 
also qualify os sensitive instructions. This would include 
a MOV instruction if allowed to access the I/O page. 
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The I/O structure of the P DP-1 1/50 is one of the true 



advantages ouilt into the system's architecture and can he 
one of the biaaest disadvantages in v i r t u r a 1 i 7 i n q the sys- 
terrif depending on how the uoper 4k of virtual memory is 
mapped into physical address space* 

It would be highly advantageous if the upper 4k virtual 
addresses of a program executing on the virtual machine were 
allowed to mao directly into the physical I/O page* and the 
access control field of the page description reoister is set 
to abort all accesses* Thus this type of sensitive instruc- 
tion is conviently traoped. If this is not the case then 
because of the flexibility of the instruction set and espe- 
cially if the program has no restrictions on the method of 
accessing the I/O page/ then one is lead to a one hundred 
percent instruction interrogation and a large increase in 
instruction simulation routines. 

The design considerations for the asychronous interac- 
tion oetween modes is based around stack operations* A stack 
is a temporay storage area (one for each mode) used in 
subroutine and interrupt service linkage* 

Individual program stacks can be directed to start at 
any virtual address and can expand either upward or down- 
ward. Any reoister can serve as a stack pointer. The main 
register used ov the system for this function is the stack 
pointer register (SP)> which by design expands downward. As 
ealier mentioned; there is a separate SP for each mode. 

Interrupts and subroutine linkage are very si miliar and 
only differ in their method of invocation and the registers 



that are stacked and loaded. Interrupts are forced while 
subroutine linkage is controlled program transfer. In addi- 
tion, subroutine linkage only effects the PC and not the PS. 
The action is basically as follows: The old PS (if caused 
by an interrupt) and the current PC are automatically 
stacked onto the new processor stack and the new linkage 
information (PS if required and PC) are placeo in the regis- 
ters. 

All interrupts are required to be simulated under a 
virtural machine, subroutine calls are not. 

This brief examination of the PDP-11/50 architecture 
clearly illustrates that the PDP-11/50 was not designed for 
supporting a vitural machine application. In fact, without 
significant hardware modifications a true virtural computer 
system can not realized. 



IV. PROBLEM DEFINITION AND POSSIBLE APPROACHES 



The current state-of-the-art of computer' science offers 
a variety of approaches that may be employed to virtualise a 
computer system. Virtualization methods can range from 
extremely expensive and complicated hardware modifications 
to that of only minor systems chances to support a limited 
type II virtual machine monitor. 

The first step in determining the type of virtualization 

x 

approach to use is to examine the computer manager's olans 
and goals for the installation. Management's desires will 
automatically eliminate many of the possible approaches. 
Therefore* a brief examination of the Naval Postgraduate 
School's PDP-11/50 computer to include the computer's en~ 
vironment* primary use* and the general goals of the school 
towards the computer system is in order* This examination 
will highlight the. imposed restrictions on virtualizing the 
system. 

A. SYSTEM ENVIRONMENT 

The Naval Postgraduate School has two PDP-11/50 comput- 
ers and a wealth of periohial devices. These computers are 
not intended to serve the school in a computer service 
bureau fashion/ but are inccroorted into a computer research 
1 aboratory. 

The orimary research areas of this computer laboratory 
are in the fields of operating systems dosinn and research* 
signal processing* computer graphics* 



and hybrid computing 



Temporary confi duration modifications 



for a specific 



research project offer no real problems. Peripherials can 
be switched between computers in matters of minutes to meet 
any new demands. This versitility is mainly do to the stan- 
dard interface of the UN IB LIS. 

Managements qoals though/ are to have all I/O devices 
ana corn outers tied together to support a real time/ mul- 
ti programming/ multiprocessing operating environment. The 
general conf i ourat i on envisioned is schematically illustrat- 
ed in appendix (B). It is a general configuration/ since the 
wide range of activities / will continually demanding confi- 
guration modifications. 

A greatly enchanced version of the UNIX ooerating system 
(called MijNIX) is being desiqned as the primary operating 
system to support the desired system environment. 

UNIX itself is a general purpose/ multiuser/ interactive 
operating system developed at Bell Laboratories. UNIX con- 
tains a number of sophisticated features generally only 
found on large systems/ but with the surprising and unusual 
quality of simplicity and ease of use. A complete and excel- 
lent abstract of UNIX is contained in reference 28. 

Even though UNIX is extremely powerful and versatile it 
would not meet the complete demands that would be required 
of the operating system. MUNIX is being developed to meet 
those addition demands of real-time processing. 
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VIRTUALIZATION GOALS AND PROBLEM AREAS 



The Naval Postgraduate School’s desire d goal in the area 
of virtualization of the P D P - 1 1 / 5 0 can be summarized as fol- 
lows: 

1* Achieve the capability to produce a virtu- 
alized PDP-11/50 computer that would supoort all 
available operating systems and be able to access 
any real or virtualized I/O device. 

2. The virtual machine's efficiency would be 
sufficient to reasonably execute most types of 
applications. 

3. Incorporate a complete debugging aid fa~ 
c i 1 i t y to assist the user in executing and pro-" 
g ramming on the virtual machine- 

The decision was made that any implementation of a vir- 
tual system would be reoui red to operate under the MU NIX 
system. This thereby eliminates any type I virtual machine 
monitor considerations. 

A futher decision and restriction was that the virtual 
machine monitor olus programs executing on the virtual 
machine would execute in the user mode and in a similar 
manner to any other process. 

This restriction imposed a serious problem on referenc- 
ing the I/O page. Since the I/O oage comprises the upper 4k 
of the address soace/ all programs on the virtual machine 
would reference this snace for testing and excut inq I/O. 



MUNIX, 



on the other hand* uses this virtual address space 



for the user stack area. 



This restriction also imposes the 



problem of having two user mode processes executing con- 
currently and in harmony but at the same time having one of 
the processes (virtual machine monitor) be the supervisor. 
It was also decided that the virtualization design would if 
at all possible/ minimize modifications to the operating 
system. 

The main problem areas identified in both the hardware 
architecture and software restrictions can now be summer- 
i z e d • 



1. That a true virtual system cannot be in- 
corporated on the PDP-11/50 as defined by 
Goldberg's Theorem 1/ since all identified sensi- 
tive instructions (appendix C) are not a subset of 
the privileged instructions# 

2. That the identified sensitive instructions 
vary in their method of execution when encountered 
in the user mode. For example/ the HALT causes a 
trap/ a RESET causes a ^o op/ and a RTI is executed 
in a normal manner/ i.e. independent of mode. 

3. That the I/O page accessing the user o r o 
gram and the M U N I X user’s space area are incompat- 
ab 1 e . 



4 . That the virtual machine monitor should be 
compl etel y separate from the job execuv i no on the 
virtual machine/ i.e. not in the same addressing 



spacer but at the same time have the ability to 
access and examine in detail the processes' regis- 
terSr PS/ and memory. The virtual machine monitor 
must also have the capability of controlling the 
o r o g r a rn s execution. 

C. MILLSTONES 

The acheivement and success of the desired goals re" 
ouires a great amount of complex design/ coding/ and process 
interaction. This is especially true if the time span re" 
quired to attain these goals includes a series of program- 
ming teams. A methodical plan must first be initiated and 
implemented in order to have the end product useable and 
efficient. Each hierarchical step of the plan must be logi- 
cally developed/ flexible/ and modular for good program con- 
trol and documentation. The following outlines the essen- 
tial milestones to meet the objectives of a truly virtual- 
i zed PDP-1 1 /50 . 

STEP 1 - Develop the basic foundation and 
necessary tools to support a limited virtual 
machine. The virtual machine would execute stand- 
alone processes subject to the following restric- 
tions. First/ interrupt handling would not be 
included. Secondly/ methods of accessing the I/O 
page would tie restricted. Finally/ only those sen- 
sitive instructions that are required for basic 



programming be simulated 



STEP ? - Devel on and incorporate a complete 



interrupt handling process. 

STEP 3 - Complete the simulation of all sensi- 
tive instructions. 

STEP 4 - Develop and include an efficient but 
unlimited I/O capability. The consolidated virtual 
machine monitor woul c now have the ability for 
supporting a virtual machine that could process 
any stand-alone job. 

STEP 5 - Complete the final enchancements of 
having the virtual machine capable of supporting 
different operating systems. 

Examination of several virtualization projects at other 
institutions* in the area of man-hour development of a pro- 
ject of this size* estimates this effort to be approximately 
one to two years depending on the implementation method. 
Our goal is to complete the first milestone* putting em- 
phasis on developing the tools* plus program modularity for 
ease of future enchancements. 

D . POSSIBLE APPROACHES 

To meet the required virtualization objectives of the 
school* four possible approaches were examined. The ap- 
proaches varied considerably in cost* soohisication* and 
implementation ease. Tne approaches were: 
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1 



Acquire if possible* virtual machine moni- 



tor software already developed for the PDP-11 com- 
puter family from anotner institution or source* 
This aoproach is the most logical and has the 
greatest appeal in first* not 'reinventing the 
wheel' * and secondly* spending the majority pro- 
gramming effort on converting and adapting it to 
our env i ronmen t . 

2 . Acquire and implement necessary hardware 
modifications to the PDP-11 system so as to im- 
prove its virtualizable characteristics. A true 
and efficient virtual system can never be realized 
on a PDP-11 computer until the execution of all 
sensitive instructions in the user mode automati- 
cally interrupt the system's processing. This type 
of modification of the hardware though* may lead 
to many undesirable side effects. For example* 
vendor maintenance aareements may be endangered* 
plus the recal possibility of degradation of normal 
processing* 

3. All proarams to be executed on the virtual 
machine would first be examined by a preprocessor. 
The function of the preprocessor would be to iden- 
tify and substitute a processor trap instruction 
for all sensitive instructions encountered. 

This approach has the advantages of being the 
most cost sensitive and relatively easy to 



implement but has three main disadvantages* First, 
the time spend for preprocessing; secondly, the 
ease of anyone intentionally or unintentionally 
beat i nq the preprocessor since data and instruct 
tions are interspersed in a program and confusion 
between the two are easily made? finally, and most 
important, the inability of processing a program 
which contains se 1 f -mod i f y i ng code. This includes 
many operating systems. 

4. Implement some extensive operating system 
modifications to ease the virtualization effort. 

Although this approach is in variance with the 
restriction on minimizing operating system modifi- 
cations, some of the major problems could be 
resolved. For instance, it woulo be highly desire*" 
able to have the I/O page available to the virtual 
processes thus solving the I/O problem and either 
eliminate or relocate the user stacks. This would 
require the operating system to distinguish a real 
from a virtual process for appropriate stack han- 
dling and memory mapping. 

Another very appealing implementation method 
is to have the virtual machine monitor execute in 
the supervisor mode while the virtual Processes 
run in the user mode. This would solve the 
memory address space problem and have the virtual 
monitor aoove the user but less then the operating 
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system. This also would require extensive modifi- 
cations since ^ U N I X only uses the kernel and user 
mode. 

There are always considerable techinical problems in 
modifying any operating system. This is especially true at 
the present time of the UNIX system. It is first/ relatively 
new to all personnel at the school/ including the C-lanquage 
which it is written i n / but more important the operating 
system is almost completely undocumented. The majority of 
effort to date has been in learninq/ documenting/ and modi- 
fying the more important areas of the system. 
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V. SELECTION AND IMPLEMENTATION 



A. SELECTION 

The preprocessor approach was selected as the method for 
virtualizing the PDP-11/50. Although this method has some 
substantial disadvantages as outlined in chapter IV/ the 
cost/ ease of implementation, and time limitations more than 
compensated for them. This method also assisted in overcom- 
ing some of the conflicts and undesireable effects of run- 
ning under MUNIX and without making any modifications to the 
MU NIX system. 

The search for existing virtual machine monitor 
software/ for the PDP-11/50/ identified only one other edu- 
cational institution involved in this area. The University 
of California/ at Los Angeles/ under the direction of Pro- 
fessor Gerald J. Ponek is currently involved in virtualizing 
a PDP-11/45 computer. One of their main research efforts to 
date has been in the area of computer security and the vir- 
tual machine. Their implementation method involves a type I 
virtual machine monitor plus an additional n 1 u gable hardware 
modification module/ (the Virtual Machine Extension 
K8S11-A)/ designed and manufactured for them by Digital 
Equipment Coporat i on (DEC). The hardware module simply plugs 
into the system when the virtual machine monitor is running 
ana efficiently traos all sensitive instructions. 

Professor Ponek was contacted for the possibility of 



using any of their software modules in our virtual machine 



mon i tor 



It was decided that at this time/ it would be very 



impractical since their virtual monitor is still in the 
development stage* written in a different language* and 
mostly undocumented. Professor P o p e k did recommend thouoh* 
that we purchase from DEC the hardware 'virtual machine 
extension'. The virtual machine extensions option (KBS11-A) 
is an available Digital Equipment Corporation option for tne 
PDP-11/45 and PDP-11/50 computers at a cost of $5995. Its 



specific function is to facilitate the writing of virtual 



machine monitor code. 

The KBSli-A provides the following features: [103 



"1. It provides the ability to trap certain "con- 
trol- sensitive" instructions when they are en- 
countered in user and/or supervisor mode. These 
instructions* characterized by the fact that they 
operate differently in user or supervisor mode 
than in kernel mode* are: 

HALT - Halt Instruction Execution 

WAIT - Wait for Interrupt 

RESET - Reset the system 

RTI - Return form Interrupt 

RTT - Return from Trap 

SPL - Set Priority Level 

MTPI - Move to Previous Instruction 
Soace 

MTPD - Move to Previous Data Space 

MFPI - Move from Previous Instruction 

Soace 

MFPD - Move from Previous Data Space 
In the virtual machine environment* these instruc- 
tions must be trapped and then simulated by the 
operating software. To aid in the servicing of 
these instructions* the KRS11-A hardware encodes 
each of these instructions into a unique 4 -bit 
number which can be read by the service routine. 
This eliminates software decoding of the instruc- 
tions. The specified instructions cause a reserved 
instruction trao* vector 10. 



2. It provides the ability to set up an al- 
ternate vector space to he used for traos and 
interrupts from user mode. The effect is to 
"offset"* by 1000* 2000* or 3000 (octal)* any vec- 
tor address generated while the processor is in 



55 



user mode. This is done so that a supervisor pro- 
gran can service certain traos from user programs 
directly while still allowing the Kernel mode pro- 
gram full control of the system (all vectors are 
in Kernel address soace). 

3. It Provides a User Stack Limit Register# 
similar in operation to the Kernel Stack Limit 
Register. without this capability# the only other 
way of limiting the user stack is by means of the 
Memory M anaaement unit# which limits virtual 
machine structure and flexibility." 



The KBS11-A option contains no operator controls# but is 
under full program control by means of three registers on 
the UNIBUS. The three registers are the following: 

1. VCSR VMX Control-Status Register - This 

( 

register contains seven control bits to enable or 
disable the various extended processor features. 

2. VC ODE VMx Reserved Instruction Code Regis- 
ter - This register contains a four bit code for 
easy identification of the instruction that caused 
the t rao. 



3. VUSL VMX User Stack Limit Register - This 
register contains the user stack limit address 
which operates like the standard kernel mode stack 
limit register. 

When the K8S11-A is disabled# the K8S11-A hardware has 
no effect and the processor operates as normal. This 
hardware ont ion solves all of the hardware problems and 
lends itself for creating a true virtual machine. The cost 
of the KBS11”A is currently the prohibitive feature# but 
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until this hardware option or one similar to it: is 



i n s t a 1 led 



the aoals of the school toward virtualization will never be 
at t ended. 

B. DESIGN CONSIDERATIONS 

With the objective of implementing a basic virtualized 
PDP-11/50 computer (chapter IV - first milestone)* the fol- 
lowing design characteristics and considerations were adoot- 
ed. 



1. The virtual machine's configuration will 
consist of one PDP-11/50 computer without a memory 
management unit* 52k words of memory* and one LA30 
DECwriter termininal. 

2. Job processing will be restricted to stan- 
dalone jobs that have been oreprocessed for sensi- 
tive instruction substitution. Jobs also will be 
restricted in the method of accessing I/O and in 
not using interrupt type processing. The ‘MOV 1 
instruction emoloyino direct indexing will be the 
only instruction allowed to reference the I/O page 
and the 'HALT' instruction will bo used for exit- 
ing from the user program. 

3. The debugging aid will include the follow- 
ing capabilities: (1) Be able to display the con- 
tents of the general registers* program status 
word and memory. Memory may be displayed both 



o c t a 1 1 y and symbolically; (?) Be able to modify 
any register or memory cell; (3) Provide the abil- 
ity for breakpoint processing. 

<4. The program will be written in the C - 
1 anguago/ ne modular in design for ease of incor- 
porating enhancements and understanding^ and in- 
corporate a built in internal debugger that will 
upon command/ give the value of the variables 
encountered throughout the program. 



C. IMPLEMENTATION 

1 . Program Overview 

The virtual machine monitor consists of the follow- 
ing functional units. (Figure 11 illustrates these function- 
al units and their relationships). 

a. Supervisor Monitor 

The supervisor monitor is the highest level 
module of the virtual monitor. It provides the main communi- 
cation between user and virtual machine. It accepts and 
edits the virtual machine monitor commands and calls and 
supervises their execution. 

b. Preprocessing Monitor 

The prpopocessinp monitor edits/ calls/ and mon- 
itors the preprocessor executions. 

c . Preprocessor 

The preprocessor is a completely self-contained 
module that examines incoming virtual machine job for 
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senstitive instructions and o ossicle substitution. Its out" 
put is a modified executable (a. out) file and a sensitive 
instruction table. 

d. Execution Monitor 

The execution monitor's function is to start or 
continue the executing of the job on the virtual machine. If 
a breakpoint or sensitive trap is encountered in the program 
the execution monitor receives the interrupt and calls the 
dispatcher for servicing. 

e. Dispatcher 

The dispatcher determines the type of problem 
encountered in the program and calls (if necessary) the 
required sensitive instruction simulator or breakpoint 
handler. 

f. Sensitive Instruction Simulators 

These routines (one for each sensitive instruc" 
tion) simulate the execution of the individual sensitive 
instructions. 

g. Debug Modules 

The debug modules are available to the general 
user for assistance in program debugging and in examining 
program execution. 

h. Internal Program Debugger 

When this is activated/ variable values used 
throughout the program are displayed to aid in a e bugging. 
This function is not intended for the general user but in- 
stead for the virtual machine's monitor maintenance* debug- 
ging* and enchancement verification. 
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i . Misce! lanpous Utility Functions 

This is a general collection of utility func- 
tions used bv the main modules. 

2 . Supervisor Monitor 

The supervisor monitor (named ’ v m rn * ) is a small 
simple routine which controls and directs the main flow of 
the program? as directed by the user's commands. It is the 
highest level module of the virtual machine monitor and the 
one that is entered when the monitor program is executec. 
Its action is simoly to wait for a user command? edit the 
command? and initiate a call to the correct module for pro- 
cessing. After the called process has completed? control is 
returned to the supervisor monitor. The supervisor monitor 
then waits for the next command. 

The following is a list of the valid commands and 
their respective functions. 



COMMAND 



FUNCTION 



P filex ty/nl lb] 



Preprocess filex. This com 



mand has two optional oarame 



ters. The first indicates 



whether the user wants to be 



informed when a sensitive 



instruction is encountered. 



The second activates the 



preprocessor's internal de 



bugger . 



e 



Start or continue program 
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execut ion 



D A DDR 



d r 



d o ADDR U 



d s ADDR U 



m rX VALUE 



m SP VALUE 



m PC ADDR 



m PS VALUE 



m mem ADDR VALUE 



Put a breakpoint at address 
ADDR 

Display oil general registers 
plus the program status word. 

Display memory in octal start- 
ing from address ADDR for a 
number of words. 

Display the program symboli- 
cally from address ADDR for U 
number of instructions. 

Modify register X to VALUE 
(octal ) 

Modify stack pointer to VALUE 
(octal). 

Modify the proaram counter to 
address ADDR. 

Modify the program status word 
t o VALUE (octal). 

Modify memory at address ADDR 
to VALUE (octal ) . 



?. 



Enter internal debug. 



6 ? 



X 



Leave internal debug 



s 



Terminate the execution of the 
virtual machine monitor. 



3. PreDrocessor 

The preorocessor program (named * <- v m m 0 0 1 ' ) is a self 
contained module whose function is normally required only 
once for each job processed on the virtual machine. Because 
of its infrequent use, the preprocessor is loaded into 
memory and executed only when needed. The preprocessor is 
called by the preprocessing monitor. The interaction 
between the preprocessing monitor and the preprocessor pro- 
gram is coordinated by a series of MU NIX system calls as 
illustrated in fiqure 12 . 

The input to the preprocessor is programs which are 
to be executed on the virtual machine.’ These programs must 
be in the form of an executable (a. out) file with non- 
sharable segments. The user program input is read into the 
preprocessor in blocks of 512 bytes for improved effeciency. 
The preprocessor program examines and tests each program 
instruction in the text segment for sensitivity. If such an 
instruction is found the 'TRAP 1 instruction (104450) re- 
places it and the sensitive instruction is then written in 
the sensitive instruction table. 

The preprocessor program has three arguments. The 
first argument is mandatory and gives the name of the pro- 
gram (a. cut file) for preprocessing. The second argument is 
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INTERACTION BETWEEN PREPROCESSING MONITOR AND PREPROCESSOR 

PREPROCESSING MONITOR 
EXECUTION 



A new system process is created 
by copying the core image of the 
caller of fork. The new process 
is the child of the old process 



FORK ( ) 




PARENT (old process) 



CHILD (new process) 



WAIT ( 



EXEC (-VMP001 ) 



Causes the parent to 
to delay execution 
until the child 
process has 
terminated. 



Program -VMP001 overlays 
child and starts execution 
at the beginning of the 
program. There is no 
return to the original 
child process. 



Continues to 
execute 




-VMP001 starts 
execution 



•r 



-VMP001 terminates 
(activates parent) 



FIGURE 12 
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optional allowing the user a choice of whether he wants to 
be notified when a sensitive instruction is encountered. 
(Default value is 'do not notify’). flhen notification is 
desired* the sensitive instruction plus the five previous 
instructions of the program and their location are 
displayed. It is at this time that the user can exercise the 
option of agreeing or disagreeing. If the user agrees* the 
'TRAP' instruction will be substituted* otherwise no substi- 
tution will be made. It must be emphasized that in the no- 
tification mode* the user decides if a sensitive instruction 
has been encountered. The final optional argument is the 
internal debug switch for the preprocessor (Default value 
'is no debug’). 

The ’JSR’ and 'TRAP' instructions have the possibil- 
ity of having a variable number of parameters following them 
(these parameters freauently look like 'JSR' or 'TRAP' in- 
structions to the preprocessor). Because of this unioue 

♦ 

characteristic* the preprocessor will automatically printout 
the five previous instructions* the sensitive instruction 
encountered* and a message reguesting the number of parame- 
ters that are following the instruction. The user can then 
indicate to the Preprocessor the number of parameters to 
skip. 

The preprocessor's output is a modified a. out file 
(named <- V mmO0(?) void of all sensitive instructions and a 
sensitive instruction table (named <-vmm003) containing the 
encountered sensitive instructions and their addresses. 

The program logic flow is illustrated in figure 13. 
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PR E PROCESSOR 




FIGURE 13 
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Execution Monitor 



The execution monitor controls the starting and res- 
tarting of orocesses executing on the virtual machine. Ml 
processes running und$r MUNIX have two executable forms. 
The first form is the a. out file for programs ready to be 
executed. The second form is the core image file used during 
execution (figure 14). The virtual machine monitor frequent- 
ly accesses one or both of them (depending on if the process 
has been initially executed). During the course of program 
execution these two files differ in location. The a. out 
file is located in the user's library while the core image 
file i s / when not executing/ located in the system's swan 
area. 

If the process has never been executed/ the execu- 
tion monitor initiates the process' execution in the seme 
manner (fork/ exec) as the preprocessor was executed (figure 
12). After the user program has initially been executed/ 
the execution monitor need onlv issue a CONTIN system call. 
This system call puts the core image file/ which is current- 
ly blocked for processing/ back on the system's process 
ready queue. The execution monitor then issues another WAIT 
system call to wait for the next interrupt. The execution 
monitor returns to the supervisor monitor only when the job 
is completed or a breakpoint has been encountered. Figure 
15 illustrates the execution monitor's program logic. 

5 . Pi snatcher 

The dispatcher is the main control module for pro- 
cessing virtual machine interrupts. The dispatcher is 
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EXECUTE 




FIGURE IS 
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i n v o 1 k e d when the program executing or. the virtual machine 
executes one of the substituted 'TRAP' instructions. 

The dispatcher determines where in the program the 
interrupt occurred, the type of interrupt, (i.e. breakpoint, 
sensitive instruction, or normal interrupt) and finally, 
what simulator or function to call. The program logic is 
illustrated in figure 16. 

6 . Debug Modu 1 es 

Plans were originally made to use the debugging pro” 
gramming modules of UNIX, but unfortunately, the debugging 
program modules were being completely revised to be used 
under MUNIX so the decision was made to write the virtual 
machine monitor's own debugger. The three primary modules of 
the debugger are the display, modify, and breakpoint. 

a . Display 

The display module is used to display the virtu- 
al machine's register values or the virtual machine's memory 
content. (Display commands are outlined in Appendix D.) 
Upon command of the user, the values of the general purpose 
registers are displayed both in octal and decimal number 
representation while the values of the PS, SP, and PC are 
displayed only in octal. Memory may be displayed in octal 
(core dump format) or symbolically. In either case, the 
memory disolay will start from where requested by the user 
for the number of words specified. Module logic flow is 
depicted in figure 17. 

The core image file is used to retrieve the 
values of the registers and the octal content of memory. 
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D I S P ATC H E R 




FIGURE 16 
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DISPLAY 




FIGURE 17 



Tnus the Program roust first be executed (produces a core 
i maoe file) before the use of these two commands ere al- 
1 owed . 

b . Modify 

The logic flow of the modify module (figure 18) 
is similar to the logic of the previously discussed display 
module. Memory is modified by the modify module on a word” 
by-word basis. As was in display module/ it is also the case 
here that the program must first be executed before a regis- 
ter is modified. Any memory modification (memory may be 
modified before execution) will automatically modify the 
a. out file and the core image file if it exists. 

c. Breakpoint 

-The breakpoint debugging facility consists of 
two basic functions. One function (BPINSERT) inserts the new 
breakpoint into the user program and the second function 
removes the breakpoint when executed (8PHANDLER). 

Up to ten breakpoints at one time can be insert- 
ed into the program and can be entered either before or dur- 
ing execution (For breakpoint commands see Appendix D). 

The BPINSERT function saves the instruction at 
the breakpoint address in an array and inserts a 'TRAP' 
(10 A 450) instruction in place of it. 

iNhen the breakpoint is executed during user pro- 
gram execution an interruot occurs and is serviced by the 
BPHANDLR (via the dispatcher). The real instruction is 
returned to the pronram and the program counter (PC) is 
backed-up one instruction to point to the returned 
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MODIFY 




FIGURE 18 
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instruction. A message? is printed to the user showing the 
instruction address anu instruction where the breakpoint was 
inserted. Program control is then returned to the supervisor 
moni tor. 

Breakpoints are removed upon execution and must 
be re-inserted upon the comoletion of a breakpoint interrupt 
each time the user desires the breakpoint to remain. 

The BPINSERT and B P H A N D L R logic flow are illus- 
trated in figure 19. 

D. TEST AND EVALUATION 

Several small standalone programs were written to test 
the reliability and performance of the virtual machine. The 
testing procedure included executing the program on the vir- 
tual machine and on the bare machine using the same input. 

All programs tested on the virtual machine executed in a 
similar fashion producing the same output as in the stan- 
dalone environment, out with a substantial and disaopointina 
lost of efficiency. For example, a small program desiqned to 
echo print a string of characters had immediate response on 
the bare machine, but took up to twenty seconds Per charac- 
ter on the virtual machine. 

The virtual machine's lack of efficiency is mainly 
caused by the need to simulate I/O to a real device, the 
user program waiting for execution in the process queue 
after the virtual machine monitor has completed its func- 
tion, and the need for updating the suoer-block via the SYNC 
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B P I N S E R T 




FIGURE 19 
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system cal) (causes all information in core memory that 
should be on disk to be written out) to insure the user core 
file is located on the disk 'swap' area before the virtual 
machine monitor can access the urogram. 

The efficiency aspect makes the virtual machine under 
its current design, highly impractical for serious utiliza- 
tion, and emphasizes the need for a hardware virtual machine 
extension. 
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VI 



CONCLUSION 



The virtual machine with its numerous applications pro- 
vides many research opportunities for an educational insti- 
tution. The virtual machine has proven itself as an extreme- 
ly valuable tool in the university computer laboratory* in 
the computer science classroom as on effective training aid* 
and in the business world as a sophisticated approach in 
solving difficult application problems. 

Although extremely limited in its current state* the 
PDP-11/50 virtual machine has arrived at the Naval Postgra- 
duate School. The first milestone has been accomplished. The 
basic foundation for a useable virtual machine with accom- 
panying debugging aids and tools has been completed. The 
virtual machine will execute stand-alone processes that corn- 
form to the stated restrictions. Nevertheless* a great deal 
remains to be accomplished to produce the type of virtual 
machine desired and needed at the Naval Postgraduate School. 

In our study* design* and implementation of this limited 
virtual machine many conclusions* afterthoughts* and recom- 
mendations have come to light. The following highlights 
some of our main conclusions and thoughts. 

1. Although we have only developed the embryo 
of the virtual machine* its usefulness is readily 
apparent. For instance* an inexperienced computer 
science student can design a simple assembler pro- 
gram and actually see and fellow the program's 
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execution by examining the program statu s , memory; 
and registers. he can r*a pidly obtain an under- 
standing of data representation versus instruction 
representation, symbolic lenguaqe versus machine 
lanouage, anti memory and CPU interaction. Basic 
I/O methods can also be explored. 

2. Being ambitious is on excellent personal 
trait, but trying to complete a new house with a 
fancy and beautiful exterior before the foundation 
is comoleted; is catastrophic. A great deal of 
time and effort should be devoted to dividing the 
problem into loqical pieces of workable sizes. 
There was a strong desire on our part to complete 
and implement a virtual machine that satisfied the 
entire school's goals for virtualization. At 
first, much time was spent in designing some of 
the more intricate and final enhancements. It was 
with great effort and some loss of pride that we 
limited our goals and establish a milestone ap- 
proach. 

3. Being the first to work on brand new 
equipment has a psychological fulfillment, but 
this joy is quickly diminished on encountering the 
ever present new hardware bugs. In the planning 
phase of new applications that will be implemented 
on new hardware (not necessarily unfamilar 
hardware) 'safety 1 factors should be incorporated 
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in the schedule. 



At worst you ore ore pared and at 



best ; you finish anead of schedule. 

A. Like new equipment/ unfamiliarity with the 
language adds a new dimension of problems. There 
is a substantial learning before one can be pro- 
ductive. This takes time/ effort/ and continuous 
self-discipline/ but is absolutely essential. 

5. Many enhancements on the POP- 11/50 were 
being accomplished concurrently in a coordinated 
team-group aporoach. A marriage of advantages 
exists in this type of real world working environ- 
ment. Few things can be substituted for actual 
experience in a hands-on integrated approach. 
Design considerations must be synchronized with 
the other teams/ working schedules must be coordi- 
nated/ and joint planning meetings must regularily 
be attended. On the other hand/ one is continually 
frustrated by files being destroyed? system 
crashes/ unknown system changes/ and lack of de- 
tailed coordination. 

6. The program design has changed consider- 
ably from the start. It is extremely difficult to 
start by developing programming standards? espe- 
cially when the language and its characteristics 
are unfamiliar. Much time was spent on reviewing 
the program for possible regrouping and 
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consolidating proaran modules. 

The first modules were generally poorly writ- 
ten/ caused mainly by lenauage unfamiliarity and 
the desire to have the program just work. As pro" 
grammino skills improved/ the program modules 
tended to become more soph i seated and clever/ and 
resulted in the disguise of the logic flow. This 
soon 'backfires' on any program of considerable 
size. Special care and time was finally taken to 
improve program modularity/ clarity/ and simplici- 
ty in program logic/ especially when it was en- 
visioned that later enhancements would be added to 
the program by other programmers. 

The use of variables was another problem area. 

They must be controlled from the beginning or it 
will quickly be too late. Variables should be 
organized to readily distinguish their purpose and 
should incorporate some type of naming conventions 
for better nrogram control and maintenance. 

One good feature of the program/ incorporation 
of an internal programming 'debugger' actuated on 
command/ has proven itself extremely useful and 
valuable. 

As previously mentioned/ there is no 'one best way' to 
design a virtual machine/ however access to various 
developed ideas and alternatives is a catalyst for futher 
research. 
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As noted throughout this thesis* there is a variety of 
ongoing activity in progress throughout the country concern- 
ing the virtual machine approach* but much more work and 
educated professionals are needed. The future of the virtu- 
al machine at the Naval Postgraduate School will not reach 
an acceptable level without careful attention. Many areas 
remain unresolved including the possible acquiring of the 
DtC virtual machine extension option and substantially modi- 
fying the operating system to alleviate the I/O problem. 

Numerous areas of research in virtual machines could be 
recommended for futher research* but until a more versatile 
virtual machine is implemented these arts will have to wait 
or be accomplished at another institution. 
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APPENDEX A 



GLOSSARY 

The purpose of the glossary is to provide a brief list 
of the more common definitions found in this thesis and 
related literature. 

1. ARCHITECTURE - Attributes of the system as seen by the 
user. It is the functional behavior and structure of the 
system where emphasis is olaced on the needs of the user. 

2. BARE MACHINE - Machine without its accompanied software. 

3. CONTROL PROGRAM ~ Generally means virtual machine monitor. 
A. EXTENDED MACHINE - The bare machine plus operating s y s - 

t em . 

5. EMULATION - Technique to map one system architecture 
into another different architecture using some type of 
firmware support. Enables the computer to execute i nst rue" 
tions of other computers. 

6. FAMILY - Series of computers with similiar architectural 
design and comoatabilities, i.e. IBM 360 family. 

7. FAMILY VIRTUALIZING - Virtual machine not identical to 
the host but is a member of the same computer family. 

8. GENERATION - Refers to the architectural characteristics 
of the computer^ i.e. second generation and third generation 
c ompu t e r s . 

9. HARDWARE VIRTUALIZER - Hardware-firmware virtual machine 
monitor that supports a virtual machine, i.e. distinct from 
software design to support e virtual machine. 



10. HYBRID VIRTUAL MACHINE - All instructions in the 
priveiened state are software interpreted. All others are 
executed directly. 

11. HOST MACHINE - Bare machine in which VMM runs. 

12. NATIVE MODE - Onerat ion of system, i.e. no emulation. 

13. PRIVILEGED INSTRUCTION - Instruction that must execute 
only in the privileqed mode for correct results. 

14. SELF-VIRTUALIZING •* The processor of the virtual comput- 
er is is identical to the host. 

15. SENSITIVE INSTRUCTION - An instruction which if permit- 
ted to execute directly on the host machine will give in- 
correct results because of the virtual machine software con- 
struction. 

16. SUPERVISOR CALL - Instruction used to call upon the 
operating system. 

17. VIRTUAL MACHINE - Isolated duplicate of a real machine. 

18. VIRTUAL MACHINE MONITOR - Software which mediates 
between the virtual machine and host, 

19. VIRTUAL MACHINE MONITOR TYPE I - Runs on a bare machine. 

20. VIRTUAL MACHINE MONITOR TYPE II - Runs under the host 
machine's operating system, 

21. VIRTUALIZATION - The creating of a virtual machine. 

22. V I RTU AL I Z ABLE - Refers to being able to create a virtual 
machine from the existing machine. 

23. VIRTUAL MACHINE RECURSION - Ability to run a virtual 
machine monitor on a virtual machine. 
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APPENDIX B 



PDP-11/50 CONFIGURATION 
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APPENDIX C 



SENSITIVE INSTRUCTIONS 

The following P D P - 1 1 / 5 0 machine instructions were deter- 
mined sensitive. The determination was based on the oremise 
that if the instruction were allowed to be executed either 
(1) the current state of the virtual machine would be inac- 
curate and/or (2) that the instruction would un i t en t i ona 1 1 y 
interfer with and/or return to the real system. It should be 
noted that some of these instructions are only sensitive due 
to the aporoach selected for producing and operating the 
virtual machine. 

GROUP 1, - These are the instructions that if exe- 
cuted would trap to the real system for interrupt 
handling instead of to the virtual machine inter- 
rupt handlers. 

1. HALT - Generates an interrupt in 
user/supervisor mode/ traps to physical 
address 4. 

2. BPT - Breakpoint interupt/ traps to 
physical address 14. 

3. IOT - I/O interruot/ traps to physi- 
cal address 20. 

4. EMT - Emulator interrupt/ traos to 
physical address 30. 

5. TRAP - Trap interrupt/ traps to phy- 
sical address 34. 
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GROUP IT 



These are the instructions 



hat if exe 



cuted would automatically change the program 
Status word (PS). This action must be simulated^ 
in a virtual interupt changing only the virtual 
PS. 

1. RTI - Return from trap. 

2. RTT - Return from trap. 

3. rt AIT - It causes the processor to 
relinquish use of the UNIX and wait for 
an external interrupt. 

GROUP III - These instructions are designed for 
inter -mode communication using the memory manage- 
ment unit. A virtualized memory management unit 
is reaui red for this instruction set. 

1. MFPD - Move from previous data space. 

2. MTPD - Move to previous data space. 

3. MFPI - Move from previous instruction 
space. 

4. M T P I - Move to previous instruction 
soace . 

GROUP IV - These instructions are NOPs in the 
user/suoervi sor mode and should reflect a change 
in the state of the virtual machine. 

1. RESET - All devices on UNIBUS are 
reset . 

2. SPL - Sets a new Priority level in 
the PS. 
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GROUP V - Miscellaneous instructions, 

1. MOV - This refers to any MOV instruc- 
tion that references the I/O page. This 
instruction is sensitive only due to the 
restriction pieced on the I/O process- 
i ng . 
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APPENDIX D 



USERS MANUAL 
FOR THE 

PDP-11/50 VIRTUAL MACHINE 



I. PURPOSE 

This users manual is primarly designed to explain how to 
execute programs on the virtual machine and how to use the 
virtual machine's debugging capability, 

II. VIRTUAL MACHINE 

1. Virtual Machine - What it is 

A virtual machine is basically a software program 
which creates the imaae and environment of a bare machine (a 
PDP-11/50 without an operating system). Programs that nor- 
mally execute on a real bare machine will execute on the 
virtual machine. 

2. Function 

The virtual machine has been used in many sophisti- 
cated applications in the computer processing world. One of 
these uses r and the primary one for this machine/ is an edu- 
cational aid for the student in computer science. 

Here the student has his own bare PDP-11 /50 computer 
to program and examine the program's execution. The virtual 
machine will execute stand-alone PDP-11/50 assembler pro- 
grams that meet the restrictions in section VII. 
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3. Debugging Capability 

The virtual machine has a simple but significant 
debugging capability. The student can display and modify 
the general ourpose registers? program counter? stack 
pointer? and nrogram status word. He can also display and 
modify memory. He can insert breakpoints at certain areas 
of his program for controlled proqram execution. 
Configuration 

The virtual machine's configuration is as follows: 

a. One PDP-11/50 computer (without memory 

management ) . 

b. 32k words of memory. 

c. One LA30 DECwriter terminal. 

III. INPUT TO THE VIRTUAL MACHINE 

Jobs to be processed on the virtual machine must con- 
form to the following characteristics. They must: 

1. be PDP-11/50 assembly programs. 

2. be in a. out file format. 

3. have non-shareable program seqments. 

4 . not incorporate any UNIX system calls. 

5. have been preprocessed by the virtual machine moni- 
tor. 

IV. GENERAL FLOW IN USING 1 HE VIRTUAL MACHINE 

1. Programmer designs? programs? and assembles his pro- 
gram. 

2. User starts up the program ' %• v m m ' . 
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User ore processes his assembled program using the 



preprocessor command of the virtual machine. 

4. Programmer, may if he desires, insert breakpoints 
into his orogram at critical areas. 

5. User executes his program using the execute command 
of the virtual machine. 

6. Programmer can at anytime while his job is not actu- 
ally executing on the virtual machine, utilize any debug 
function. 

7. when program has terminated, user can stop the vir- 
tual machine by the termination command. 

V. VIRTUAL MACHINE COMMANDS 

The following is a list of the valid commands and their 
resnective functions. All addresses (ADDR) and required 
values (VALUE) must be expressed in octal. 



COMMAND 



FUNCTION 



p f i 1 e x ( y / n 1 



Preprocess filex. This com 



mand has one optional parame 



ter. The parameter indicates 



whether the user wants to be 



informed when a sensitive 



instruction is encountered. 



e 



Start or continue program exe 



cut i on 



b ADDR 



Put a breakpoint at address 
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ADDR 



d r 


Display all general reqister 

plus the program status word. 


d o A D 0 R U 


Display memory starting from 
address ADDR for tt number of 
words. 


d s ADD R tt 


Display the program symboli- 
cally from address ADDR for tt 
number of instructions. 


m rX VALUE 


Modify register X to VALUE 


m SP VALUE 


Modify stack pointer to VALUE. 


m PC ADOR 


Modify the program counter 

with address ADDR. 


m PS VALUE 


Modify the program status word 
to VALUE. 


m mem ADDR VALUE 


Modify memory at address ADDR 
to VALUE. 


s 


Terminate the execution of the 
virtual machine monitor. 



VI. PREPROCESSOR 



The preprocessor 


examines the user's programs for sen$i~ 



t i v e instruction?, (instructions that can not be allowed to 
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directly execute). As illustrated a bo ve in tne virtual 
machine commands, the preorocessor has two parameters. The 
first parameter is manditory and is the user's program name? 
the second oar a meter is optional, allowing the user a choice 
of whether he wants to be notified when a sensitive instruc- 
tion is encountered. When notification is desired, the sen- 
sitive instruction plus the five previous instructions of 
the program and their location will be displayed. After 
examining these instructions the user can agree or disagree 
with the oreprocessor. The user's decision is accepted by 
the preorocessor so user BEWARE. 

The 'JSR' and 'TRAP' instructions have the possibility 
of having a variable number of parameters following them 
(these parameters frequently look like sensitive instruc- 
tions to the preprocessor). Because of this unique charac- 
teristic, the preprocessor will automatically printout the 
five previous instructions, the 'JSR' and 'TRAP' instruction 
encountered, and a message requesting the number of parame- 
ters that are following the instruction. The user can then 
indicate to the preprocessor the number of parameters to 
skip. 

VII. BASIC RULES AND RESTRICTIONS 

1. All files must be an a. out file and be preprocessed 
before any command will function on the virtual machine 
including file execution. 

2 . All files will be stand-alone type processes, and 
must not use any UNIX system calls (READ, WRITE, EXIT, 
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ETC. ) 



3. Files cannot employ any interrupt type processing. 

4 . Files must perform their own I/O routines. I/O is 

restricted in the method used to access the I/O page. A 1 i 

access to the I/O page will be Performed only by the 'MOV' 
instruction^ and then only by direct indexing. I/O access- 
ing is limited to the four LA30 DEC writer registers. (see 
DEC peripherals handbook). 

5. File must first be executed before displaying or 
modifying registers/ or in displaying memory in octal. 

6. Files will use the 'HALT' instruction for normal 

exiting from their orogram. 

7. The following assembler instructions will be treat- 
ed as NOP instructions: MFPD , MTPD, MFPI, MTPI, RESET/ WAIT/ 
RTI, R T T / and SPL. 

8. The user should be cautioned against inserting a 

breakpoint within an I/O (loop) routine that inputs a string 
of characters. when a breakooint is encountered the remain- 
ing characters for insertion will be lost. 

VIII. FILE NAMES AND FUNCTION 

1. '«-vmm' - Name of the virtual machine monitor pro- 

gram the initially creates and controls the virtual machine. 

2 . 'evmpOOl* - Name of the preprocessor program. 

3. '<-vmmOOP' - Name given to the user program after 
user program is is modified by the oreprocessor. 

A. ' e v m t 0 0 3 ' - An array of sensitive instructions and 

addresses in the user program by the preprocessor . 
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